<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/2000/REC-xhtml1-20000126/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type" content="text/html; charset=iso-8859-1" />
<title>SLF4J Error Codes</title>
<link rel="stylesheet" type="text/css" media="screen" href="css/site.css" />
</head>
<body>
    <script type="text/javascript">prefix='';</script>

    <script src="templates/header.js" type="text/javascript"></script>
    <div id="left">
      <script src="templates/left.js" type="text/javascript"></script>
    </div>

    <div id="content">

    <center>
      <h2>SLF4J warning or error messages and their meanings</h2>     
      
    </center>
    

    <h3>
      <a name="release" href="#release">
        The method
        <code>o.a.commons.logging.impl.SLF4FLogFactory#release</code>
        was invoked.
      </a>
    </h3>

    <p>Given the structure of the commons-logging API, in particular
    as implemented by SLF4J, the
    <code>o.a.commons.logging.impl.SLF4FLogFactory#release()</code>
    method should never be called. However, depending on the
    deployment of <em>commons-logging.jar</em> files in your servlet
    container, <code>release()</code> method may be unexpectedly
    invoked by a copy of
    <code>org.apache.commons.logging.LogFactory</code> class shipping
    with <em>commons-logging.jar</em>.
    </p>

    <p>This is a relatively common occurrence with recent versions of
    Tomcat, especially if you place <em>jcl-over-slf4j.jar</em> in
    <em>WEB-INF/lib</em> directory of your web-application instead of
    <em>$TOMCAT_HOME/common/lib</em>, where $TOMCAT_HOME stands for
    the directory where Tomcat is installed. In order to fully benefit
    from the stability offered by <em>jcl-over-slf4j.jar</em>, we
    recommend that you place <em>jcl-over-slf4j.jar</em> in
    <em>$TOMCAT_HOME/common/lib</em> without placing a copy in your
    web-applications.
    </p>

    <p>Please also see <a
    href="http://bugzilla.slf4j.org/show_bug.cgi?id=22">bug
    #22</a>.</p>
    
 
    <h3>
      <a name="unsupported_operation_in_jcl_over_slf4j" href="#unsupported_operation_in_jcl_over_slf4j">
        Operation [suchAndSuch] is not supported in jcl-over-slf4j.
      </a>
    </h3>

    <p>An <code>UnsuportedOperationException</code> is thrown whenever
    one of the protected methods introduced in JCL 1.1 are
    invoked. These methods are invoked by <code>LogFactory</code>
    implementations shipping with
    <em>commons-logging.jar</em>. However, the <code>LogFactory</code>
    implemented by <em>jcl-over-slf4j.jar</em>, namely
    SLF4FLogFactory, does not call any of these methods.
    </p>

    <p>If you observe this problem, then it is highly probable that you
    have a copy of <em>commons-logging.jar</em> in your class path
    overriding the classes shipping with
    <em>jcl-over-slf4j.jar</em>. Note that this issue is very similar
    in nature to the warning issued when the
    "o.a.commons.logging.impl.SLF4FLogFactory.release()" method is
    invoked, discussed in the previous item.
    </p>

    <h3>
      <a name="StaticLoggerBinder" href="#StaticLoggerBinder">
        Failed to load class
        <code>org.slf4j.impl.StaticLoggerBinder</code>
      </a>
    </h3>
    
    <p>This error is reported when the
    <code>org.slf4j.impl.StaticLoggerBinder</code> class could not be
    loaded into memory.  This happens when no appropriate SLF4J
    binding could be found on the class path. Placing one (and only
    one) of <em>slf4j-nop.jar</em>, <em>slf4j-simple.jar</em>,
    <em>slf4j-log4j12.jar</em>, <em>slf4j-jdk14.jar</em> or
    <em>logback-classic.jar</em> on the class path should solve the
    problem.
    </p>

    <p>You can download SLF4J bindings from the project <a
    href="http://www.slf4j.org/download.html">download page</a>. </p>

    <!-- ====================================================== -->
    <h3>
      <a name="illegalAccess" href="">java.lang.IllegalAccessError: tried to access field
      org.slf4j.impl.StaticLoggerBinder.SINGLETON from class
      org.slf4j.LoggerFactory</a>
    </h3>

    <p>When this errors occurs, the exception looks as follows:</p>
    <p class="source">java.lang.IllegalAccessError: tried to access field org.slf4j.impl.StaticLoggerBinder.SINGLETON \
     from class org.slf4j.LoggerFactory
  at org.slf4j.LoggerFactory.&lt;clinit&gt;(LoggerFactory.java:60)
  ... </p>

    <p>The error is caused by the static initilizer of the
    <code>LoggerFactory</code> class attempting to directly access the
    SINGLETON field of
    <code>org.slf4j.impl.StaticLoggerBinder</code>. While this was
    allowed in SLF4J 1.5.5 and earlier, in 1.5.6 and later the
    SINGLETON field has been marked as private access.
    </p>
    
    <p>From a broader perspective, this issue is a manifestation of
    problems encountered when mixing different versions of SLF4J
    artifacts.  Please also refer to the relevant <a
    href="faq.html#compatibility">FAQ entry</a>.
    </p>

    <!-- ====================================================== -->
    <h3>
      <a name="multiple_bindings" href="#multiple_bindings">Multiple
      bindings were found on the class path</a>
    </h3>


    <p>SLF4J API is desinged to bind with one and only one underlying
    logging framework at a time. If more than one binding is present
    on the class path, SLF4J will emit a warning, listing the location
    of those bindings. When this happens, select the one and only one
    binding you wish to use, and remove the other bindings.
    </p>

    <p>For example, if you have both
    <em>slf4j-simple-1.5.8.jar</em> and
    <em>slf4j-nop-1.5.8.jar</em> on the class path and you wish
    to use the nop (no-operation) binding, then remove
    <em>slf4j-simple-1.5.8.jar</em> from the class parh.</p>





    <!-- ====================================================== -->
    <h3>
      <a name="null_LF" href="#null_LF">Logging factory implementation
      cannot be null</a>
    </h3>

    <p>This error is reported when the <code>LoggerFactory</code>
    class could not find an appropriate binding. Placing one (and only
    one) of <em>slf4j-nop.jar</em>, <em>slf4j-simple.jar</em>,
    <em>slf4j-log4j12.jar</em>, <em>slf4j-jdk14.jar</em> or
    <em>logback-classic.jar</em> on the class path should prove to be
    an effective remedy.
    </p>

    
    <h3>
      <a name="no_static_mdc_binder"
      href="#no_static_mdc_binder">Failed to load class
      "org.slf4j.impl.StaticMDCBinder"
      </a>
    </h3>
    
    <p>This error indicates that appropriate SLF4J binding could not
    be found on the class path. Placing one (and only one) of
    <em>slf4j-nop.jar</em>, <em>slf4j-simple.jar</em>,
    <em>slf4j-log4j12.jar</em>, <em>slf4j-jdk14.jar</em> or
    <em>logback-classic.jar</em> on the class path should solve the
    problem.
    </p>

    <h3>
      <a name="null_MDCA" href="#null_MDCA">MDCAdapter cannot be null
      </a>
    </h3>

    <p>This error is reported when <code>org.slf4j.MDC</code> class
    has not been initialized correctly. Same cause and remedy as the
    previously listed item.
    </p>

    
    <h3><a name="log4j_version" href="#log4j_version">SLF4J versions
    1.4.0 and later requires log4j 1.2.12 or later</a></h3>

    <p>The trace level was added to log4j in version 1.2.12 released
    on August 29, 2005. The trace level was added to the SLF4J API in
    version 1.4.0 on May 16th, 2007. Thus, starting with SLF4J 1.4.0,
    the log4j binding for SLF4J requires log4j version 1.2.12 or
    above.
    </p>

    <p>However, as reported in <a
    href="http://bugzilla.slf4j.org/show_bug.cgi?id=68">bug 68</a>, in
    some environments it may be difficult to upgrade the log4j
    version. To accommodate such circumstances, SLF4J's
    <code>Log4jLoggerAdapter</code> will map the TRACE level as
    DEBUG.</p>
    


    <h3><a name="version_mismatch" href="#version_mismatch">slf4j-api
    version does not match that of the binding</a></h3>

    <p>Mixing mixing different versions of slf4j artifacts can cause
    problems. For example, if you are using slf4j-api-1.5.5.jar, then
    you should also use slf4j-simple-1.5.5.jar, using
    slf4j-simple-1.4.2.jar will not work.
    </p>

    <p>In general, you should take sure that the slf4j-api version
    matches that of the slf4j binding.
    </p>

    <p>At initialization time, if SLF4J suspects that there may be a
    mismatch problem, it emits a warning about the said mismatch.
    </p>

    <p>For the exact details of the version mismatch detection
    mechanism, please refer to the <a
    href="faq.html#version_checks">relevant entry</a> in the FAQ.
    </p>

    <h3><a name="substituteLogger" href="#substituteLogger">Substitute
    loggers were created during the default configuration phase of the
    underlying logging system</a></h3>

    <p>Highly configurable logging systems such as logback and log4j
    may create components which invoke loggers during their own
    initialization.  See issue <a
    href="http://jira.qos.ch/browse/LBCORE-47">lbcore-47</a> for a
    typical occurrence. However, since the binding process with SLF4J
    has not yet completed (because the underlying logging system was
    not yet completely loaded into memory), it is not possible to
    honor such logger creation requests, resulting in a
    <code>NullPointerException</code>.</p>

    <p>To avoid this chicken-and-egg problem, SLF4J substitutes a
    no-operation logger factory during this initialization
    phase. However, the substitute loggers returned during this phase
    are not operational. They are nop implementations.
    </p>
  
    <p>If any substitute logger had to be created, SLF4J will emit a
    warning listing such nop loggers. This warning is intended to let
    you know that you should not expect any logging output from these
    loggers.
    </p>

    <p>The only way to obtain output from the listed loggers, is to
    isolate the components invoking these loggers and to exclude them
    from the default configuration. Both logback and log4j allow
    multi-step configuration. It follows that the problematic
    components should be configured in a second step separate from
    default configuration.
    </p>

    <p>If you are not interested in the output from any of the
    substitute loggers, then no action is required on your part.</p>



</div>
</body>
</html>
 